Les logs d’une application LLM contiennent typiquement l’intégralité des prompts et des réponses du modèle, incluant les données personnelles que les utilisateurs ont introduites — nommément, incidemment ou en confidence. Un chatbot RH qui logue l’intégralité des échanges capture les salaires, les problèmes de santé, les plaintes nominatives. Un assistant commercial logue les emails, téléphones, données bancaires qui transitent dans les conversations. En l’absence d’une stratégie dédiée, cette collecte opportuniste constitue le plus grand angle mort RGPD des déploiements LLM en 2026. Pire : ces logs sont souvent stockés dans des pipelines d’observabilité (Datadog, Elastic, Grafana Loki) partagés avec d’autres équipes, créant un périmètre d’exposition massif. Cet article détaille la méthodologie pour détecter et prévenir les fuites PII dans les logs d’une application LLM.
À retenir en 30 secondes : la détection PII dans les logs LLM repose sur une combinaison de regex pour les patterns déterministes (email, téléphone, IBAN, numéro de sécurité sociale) et de modèles NER (named entity recognition) pour les patterns probabilistes (noms, adresses). La prévention passe par un pipeline de redaction en amont du log sink, et par une politique de rétention stricte. L’alternative — logger uniquement des métadonnées (longueurs, catégories) sans contenu brut — est souvent la plus sûre dès que c’est possible.
L’inventaire des PII qu’on retrouve dans les logs
Un audit de logs LLM en production révèle systématiquement les mêmes catégories de données personnelles. Les identifiants directs : emails, téléphones, noms et prénoms, adresses postales, dates de naissance. Les identifiants administratifs : numéros de sécurité sociale, numéros de pièce d’identité, IBAN, numéros fiscaux. Les données sensibles au sens de l’article 9 du RGPD : données de santé révélées en conversation, orientation politique ou religieuse, données syndicales. Les identifiants techniques : adresses IP, cookies, device fingerprints, UUIDs utilisateurs. Chaque catégorie demande une stratégie de détection et de redaction appropriée. L’erreur courante est de ne traiter que les emails et les numéros, en négligeant les noms (plus difficiles à détecter mais tout aussi identifiants).
Détection déterministe : patterns et regex
Les identifiants au format normalisé se détectent par regex. Les librairies open source comme Microsoft Presidio ou Spacy-PII fournissent des recognizers pré-construits pour les formats français (NIR, NIR provisoire, numéro de carte vitale, carte bancaire, IBAN FR, SIRET). Pour des formats métier spécifiques (identifiant client interne, numéro de contrat), des recognizers custom se définissent en 10 lignes. L’avantage de l’approche déterministe : taux de faux positif très bas (sauf collisions), performance négligeable, auditabilité totale. L’inconvénient : elle ne couvre que les formats structurés.
Détection probabiliste : NER et modèles dédiés
Pour les PII non structurées — noms, lieux, organisations — les regex ne suffisent pas. La détection repose alors sur un modèle NER (named entity recognition) spécialisé. Trois options en 2026 : les modèles généralistes multilingues (bert-base-multilingual-cased-ner), les modèles spécialisés francophones (camembert-ner), ou les modèles PII dédiés (Presidio inclut un NER basé sur Spacy, ou peut déléguer à un modèle plus performant). Pour un contexte français en production, un modèle camembert-ner fine-tuné sur un corpus annoté interne offre le meilleur compromis. L’intégration dans Presidio permet de combiner regex et NER dans un même pipeline, avec un score de confiance par entité détectée.
Mettre en place le pipeline de redaction
Le pattern cible : intercepter chaque prompt et chaque réponse avant écriture dans les logs, appliquer la détection et la redaction, puis logger la version redactée. L’implémentation la plus propre place ce traitement dans un middleware (via LangChain callbacks, LangGraph interrupts, ou un décorateur Python). La redaction peut masquer (remplacement par [EMAIL], [PERSON]), hasher (préserver la cohérence sans révéler), ou substituer par un faux équivalent (préserver la lisibilité). Dans tous les cas, un identifiant stable (hash) permet de corréler sans révéler. Trois pièges à éviter : (1) ne pas appliquer la redaction aux logs d’erreur (ils capturent souvent le prompt complet dans une exception) ; (2) ne pas oublier les traces OpenTelemetry — un sujet que nous avons traité dans notre guide sur l’observabilité des systèmes LLM ; (3) ne pas s’arrêter aux prompts utilisateur en négligeant les sorties du modèle, qui peuvent contenir des PII générées ou répétées.
Alternative : logger uniquement des métadonnées
Pour beaucoup de cas d’usage, la stratégie la plus sûre et la plus simple est de ne pas logger le contenu brut des prompts et réponses. On loggue à la place : hash de la requête (pour détecter les doublons), longueur en tokens, intent détecté, catégorie de réponse, latence, coût. Ces métadonnées suffisent pour l’observabilité technique (performance, SLA, dérive de coût) et ne portent aucune PII. Les traces complètes avec contenu sont conservées uniquement dans un journal d’audit séparé, à rétention courte (7 à 30 jours), à accès très restreint, chiffré au repos, et chiffré par entrée utilisateur (une clé par utilisateur, supprimée sur demande d’effacement). Cette architecture minimise massivement le risque, au prix d’une rigueur méthodologique accrue. LLMOps : guide complet pour déployer et opérer un LLM en production
Conformité RGPD, AI Act et obligations formelles
Les logs contenant des PII constituent un traitement de données personnelles à documenter dans le registre, avec base légale (généralement intérêt légitime), finalité (observabilité, debug), durée de rétention proportionnée, et destinataires. L’information des utilisateurs doit mentionner explicitement que leurs échanges peuvent être enregistrés à des fins de qualité et d’amélioration. Les procédures de droit d’accès et de droit à l’effacement doivent inclure les logs. L’AI Act renforce ces obligations pour les systèmes à haut risque, exigeant une traçabilité documentée des flux de données — un sujet que nous avons détaillé dans notre guide sur l’AI Act européen pour les entreprises françaises. Les équipes qui gèrent cette conformité avec maturité tiennent systématiquement une matrice logs × catégories de données × base légale × rétention, auditée annuellement par le DPO.
Pour aller plus loin côté outillage pratique, la documentation officielle de Microsoft Presidio couvre à la fois la détection, la redaction et les patterns de déploiement en production.
Mon point de vue d’expert
En audit RGPD d’applications LLM, les logs sont presque systématiquement l’angle mort majeur. Les équipes technique font un travail soigné sur l’inférence et le serving, puis déversent l’intégralité des échanges dans un pipeline Datadog ou Elastic sans aucun traitement. C’est une violation claire du principe de minimisation du RGPD, et un risque réputationnel énorme en cas de fuite. Mon conseil pour les équipes françaises : traitez vos logs LLM comme une base de données personnelles de première classe. Faites-les auditer par votre DPO dès le prototype, prévoyez un pipeline de redaction automatique sur la stack d’observabilité, et préférez quand c’est possible la stratégie « métadonnées only + journal d’audit chiffré ». Vous éviterez un contentieux CNIL potentiel, et vous construirez une architecture robuste qui tiendra face aux exigences croissantes des régulateurs.
FAQ : fuites PII dans les logs LLM
- Faut-il absolument chiffrer les logs contenant des PII ?
- Le chiffrement au repos est une mesure de sécurité attendue par la CNIL dès que des données personnelles sont stockées. Pour les logs à forte sensibilité (santé, données de l’article 9), le chiffrement par entrée avec une clé propre à l’utilisateur est fortement recommandé car il permet de garantir l’effacement effectif (destruction de la clé). Pour les logs à moindre sensibilité, le chiffrement at-rest du volume de stockage peut suffire.
- Quelle durée de rétention est acceptable ?
- Il n’existe pas de durée universelle, c’est la proportionnalité à la finalité qui compte. Pour du debug technique : 7 à 30 jours. Pour de l’analyse qualité : 90 jours typiquement. Pour de l’audit sécurité : 12 mois maximum avec justification. Au-delà, documenter spécifiquement la nécessité, ou passer à de l’anonymisation forte et conservation prolongée.
- Peut-on utiliser un LLM pour détecter les PII ?
- Techniquement oui, et certaines équipes le font avec de bons résultats qualitatifs. Mais c’est coûteux (surcoût d’inférence sur chaque log) et paradoxal (vous envoyez à un LLM externe les données que vous essayez de protéger). Les outils dédiés (Presidio, modèles NER spécialisés) offrent un bien meilleur rapport performance/coût et un contrôle plus simple.
- Comment gérer les PII dans les stack traces d’erreur ?
- C’est l’un des angles morts les plus fréquents : le middleware de redaction s’applique aux logs applicatifs, mais pas aux exceptions levées qui capturent souvent le prompt complet. La bonne pratique est d’intercepter aussi les gestionnaires d’erreur (via Sentry hooks, middlewares de framework) et d’y appliquer la même redaction. Un pentest ciblé sur ce point révèle quasi systématiquement des fuites non traitées.